I find that there are more than a few confused users out there when it comes to the way our industry uses some terms. Take the title of this chapter, for example. In any given week, you might see four, five, or even more client/server articles in the trade press (depending on which ones you read). For the most part, these articles are talking about the client/server model of database managementnot client/server networking. The fact that everyone uses the term client/server without qualifying it, however, makes this term a source of constant confusion.
We'll talk about client/server networking in this chapter. I won't keep using the full term, but you can count on it remaining consistent throughout the chapter. Client/server is the kind of support that Novell's NetWare provides. In essence, a client like your workstation logs into another PC that provides file and print servers as a minimum. The other PC doesn't provide any form of user interface that a user would need. Its user interface is specifically designed to meet the needs of the network. A client/server network has the advantage of providing total support for a network's needs. The negative aspect of a client/server network is that you have to give up a machine to use it. Needless to say, Windows NT Workstation doesn't support client/server networking as a server; it uses the peer-to-peer model. We discussed all the details of that support in Chapter 21.
The following paragraphs will provide you with the information you need to use Windows NT within a client/server network. I'm going to take a longer look at what that means, and then cover some of the details you'll need to know. We'll use a NetWare file server throughout this chapter; if you're using a different kind of network, most of the principles will apply but the implementation details will differ.
Connecting to a NetWare server is fairly easy under Windows NT. The first thing you'll need to do is install networking support. That should have been part of the installation process, but you can also do it manually after the fact. I showed you how to add services in Chapter 21. You'll need to make sure that the Workstation service is installed as a minimum before you proceed.
After you can access the network as a workstation, you'll have to get an account on the file server. Your network administrator can do this for you. If you are the network administrator, you'll have to use the NetWare SYSCON utility to add a user if you're using an older version of NetWare. Newer versions use the NDS utility, NWADMIN, to get the job done. (You can also use the NETADMIN character mode equivalent from the DOS prompt, but I won't cover that utility in this chapter because the Windows version is easier to use.) All you need to do is follow the instructions provided with your copy of NetWare to add the user account.
Now that you have an account to use, you have to install NetWare-specific support on your workstation. This means installing the NWLink IPX/SPX Compatible Transport and NWLink NetBIOS protocols, and the Client Service for NetWare service as a minimum. You need these services to access the file server at all. I've already covered the procedures for installing new services and protocols in Chapter 21, so we won't talk about them again here.
Obviously, this is a very shortened version of the process you'll follow if you have to do things manually. I think you'll find that accessing a NetWare server using Windows NT is a lot easier than what you went through under Windows 3.x, however. Of course, the usual problems remain. The big one to check on before you even start is whether you have the most current drivers. Windows 95 barely got out the door before Microsoft and Novell both started issuing new drivers; Windows NT will probably have the same problem to a certain degree. NDS support wasn't the only problem with that product. The bottom line is that you'll need to check all your drivers first and install them second.
Installing NetWare support on your workstation also adds a new applet to the Control Panel: CSNW. Figure 22.1 shows the Client Services for NetWare dialog box that appears when you open this applet. You've probably seen this before, because Windows NT displays it during the client installation process.
Figure 22.1. You can use the Client Services for NetWare dialog box to configure your NetWare connection.
This dialog box contains three sections. The first section defines the way in which you'll log into the network. You can choose to look for a specific server or to use the NetWare Directory Services (NDS) specific method of tree and context. The second section defines your print options. You decide whether to process a login script in the third section. I'll cover the first two issues in this section of the chapter. Take a look at the section "Login Scripts" for more information on login scripts.
Let's spend a few moments talking about how you can log into a server. Obviously, the first method is for systems that use bindery emulation. All 3.x servers use bindery emulation. You have a choice between bindery emulation and NDS when you install NetWare 4.x. All Windows NT will do is request the nearest server with the name you specify. This is the name that appears when you type an SLIST command at the DOS prompt after making a connection to the file server. Fortunately, this is one of the few commands you can use without actually logging into the file server.
If your NetWare 4.x server is set up for NDS, you need to select the second option. In this case, you need to enter the name of a tree and context. I'll describe these terms a bit more in the section "Using NetWare Directory Services (NDS)." The simple view for right now is that the Tree entry defines the server's position in the organization's hierarchy, whereas the Context entry defines how you'll interact with that server.
Now that we've gotten the login process out of the way (at least for the moment), let's take a look at the simple print options the Client Service for Network dialog box provides. You'll need to decide three different issues: using form feeds, getting print job completion notification, and printing a banner.
In most cases, you'll want to disable the Add Form Feed checkbox. This option sends an extra form feed after a print job completes. Because most applications already do this, you'll just waste paper if you choose it. I used to have DOS applications that stopped printing when the text was complete; they didn't move the paper up to the beginning of the next page for you. It's been a long time since I've seen one of those applications, and I don't remember seeing one at all while working under Windows. Suffice it to say that you'll want to check your applications before enabling this checkbox.
The Notify When Printed checkbox is pretty handy. Unlike the days of DOS when your printer was attached to your workstation, networks tend to keep printers in one room. You no longer get auditory or visual cues when your print job is done. This option allows you to continue working until the print job is complete. Then you can go to the printer area to pick it up. This is one of those personal preference options. I normally enable it unless I don't want to be disturbed about a low priority print job. You'll need to decide whether the interruption is worth it for you.
Network printers also share one other feature that you didn't have in the world of non-networked machines. Everyone on the network shares one or more printers, which means that you're bound to have confusion about print jobs from time to time. The third print option, Print Banner, is designed to at least partially alleviate this problem. It sends a banner with your name to the printer. Because each print job is separated by a banner page, you can figure out who owns which print job. It's also easy for an assistant to put each person's print job in a mail slot for them to retrieve later. I always enable this option because there isn't any other good way to sort through the chaos otherwise.
Tip: There's a negative side to the Print Banner option: You waste a sheet of paper for each print job. Some environmentally aware companies might view this as a real waste of trees and an easy way to fill our already overflowing landfills, and in a way it is. The alternative is pretty obvious. In this day of relatively reliable electronic mail, sharing information electronically rather than printing it out is probably a better solution. Don't uncheck this item to save trees, the confusion just isn't worth it; use electronic mail instead of printing whenever possible.
Windows NT provides several support mechanisms for login scripts. The best support is for Novell's NetWare, but the same principles hold true (for the most part) with any other network operating system (NOS) that Windows NT supports. Because Windows NT doesn't support any real-mode networks like the older versions of LANtastic, you won't have that headache to worry about. There are no AUTOEXEC.BAT configuration options to worry about or the problems associated with loading drivers before you load Windows. All those problems disappeared with Windows 3.x (although you can still support a real-mode network with Windows 95, most vendors are coming out with Windows 95 specific versions that don't rely on real-mode drivers). The only scripting support you need to worry about is that provided by larger NOS, such as NetWare, that also provide protected-mode drivers for Windows NT.
Some of you might have installed Windows NT over an existing Windows 3.x installation. Scripting support in that environment was less than perfect. In fact, it was pretty close to non-existent. The first thing you'll need to do is disable any batch files that you used to use under Windows 3.x. You don't need to log into the network or perform any script processing before entering Windows NT. Generally, you won't have to perform script processing as a separate activity; Windows NT does it for you after you log in. Any workstations that use NetWare must have an account on the server before you try to install Client for NetWare.
To enable login script processing on the NetWare server, you need to check the Client Service for NetWare dialog box shown in Figure 22.1. We've already covered the basics of this dialog box in previous sections of this chapter, so I won't cover them again here. This dialog box has three functional areas. The one you're interested in is the checkbox that enables login script processing.
Tip: You can reduce your need to use the MAP command (or anything similar) by using the persistent mapping capability available by using Explorer or the context menu of Network Neighborhood. We covered the Explorer part of the equation in the "Explorer: Borrowed from Windows 95" section of Chapter 2, "Exploring the Interface." You'll find the Network Neighborhood described in this chapter. Using the native Windows NT capability means less chance of error if an individual workstation's configuration changes.
Enabling login script processing allows an administrator to maintain the pre-Windows NT security policy on the server. It also provides a means for creating automatic search mapping and other NOS-specific features. You'll need to check the documentation that came with your network to see exactly what types of script file processing you can perform.
Note: The system login script for a NetWare server using bindery emulation is stored in NET$LOG.DAT. You'll find it in the \PUBLIC directory. The individual user scripts will appear in their \MAIL directory.
Warning: The Windows NT protected-mode script processor can't run TSRs. The TSR will start in a separate virtual machine, which will terminate with an error when the script file processing completes. This lack of TSR processing in your script files means that you'll have to come up with a different way to install backup agents and other files that you normally install using the login script. In most cases, you'll need to install such files as part of a DOS session after you start Windows NT.
So what does a typical NetWare script look like? Figure 22.2 shows one of the bindery emulation mode scripts I've created in the past. I usually keep mine very short and very simple. Remember that you don't need to use drive mappings anymore. Search mappings (essentially, the NetWare form of a path statement) are required. I also leave out the various greeting statements that a lot of administrators included in the past because the user won't see them anyway. Why waste the time processing a statement the user won't really get to see? If you take out the drive mappings, TSRs, and other non-essential statements, you'll end up with something very short and concise. I think you'll find that it's worth the effort to make the change because the user will see a definite decrease in the amount of time required to log into the network.
Figure 22.2. You'll find the user scripts in SYSCON when using bindery emulation mode.
NDS scripts like the one shown in Figure 22.3 offer a few more opportunities due to their object-oriented nature. You also get a nice Windows GUI interface instead of the DOS utility interface shown in Figure 22.2. Overall, though, you'll see little difference between an NDS and a bindery emulation script except in syntax.
Figure 22.3. NWADMIN provides script functionality when using NDS.
As you can see, this script provides the same search mapping that the script shown in Figure 22.2 does. There are some differences, thoughsome of which shouldn't be there. Novell decided to shorten INSERT to INS, for example, when they created the NDS script commands. I don't like to type any more than the next person, but it would've been nice if they had maintained a compatible wording mode for those folks moving from NetWare 3.x to 4.x. As a result of these little changes, I ended up rewriting all my scripts. Suffice it to say that if you're making the move from 3.x to 4.x, watch the wording of your scripts. Otherwise, you might get some unexpected results when users run the scripts you've moved from one environment to the other.
Network Neighborhood is a kind of expanded Explorer. There are several important differences that I think we need to cover, though. First, let's open a copy of Network Neighborhood. You can do this in one of two waysmuch like there are two ways for most of the default icons Windows NT provides. The normal double-click method produces a single-pane view like the one shown in Figure 22.4. The same figure shows the double-paned view you get by pressing Shift while double-clicking the Network Neighborhood icon. I find the second view a bit more helpful when I'm trying to find something. The first view is handy when I know what I'm looking for and need to do something like map a drive.
Figure 22.4. You can use one of two views in Network Neighborhood to cruise your network.
Once you get past the machines that you see on the network, using Network Neighborhood is much like any other Explorer activity. All you need to do is select a machine to view the drives it contains. From that point on, you can go through the directory hierarchy to find the file you need. Unlike Explorer, you don't have to map a drive before you see it in Network Neighborhood. You automatically see all the resources at your disposal.
There's an important consideration here. Network Neighborhood only shows the resources you can access. If you don't see a particular resource listed, it might mean that you don't have access to it. A check with the network administrator will tell you whether you have access to a particular resource.
Windows NT provides a lot of different utility programs to help you manage your network. One of the most important is the Server applet you'll find in the Control Panel. Figure 22.5 shows the initial display for this applet.
Figure 22.5. The Server applet provides you with a quick view of your machine's status as a server.
The one main informational area is Usage Summary. It provides you with four statistics: Sessions, Open Files, File Locks, and Open Named Pipes. The Sessions statistic tells you how many people are logged inor, more specifically, how many open logins there are. One person could log in more than one time. Each time he logs in counts as one session. The Open Files statistic tells you how many data and executable files are open at the moment, while the File Locks statistic tells how many file locks are in force. One file could be locked by multiple users. In addition, a file lock may include system files as well as data and executable files. The Open Named Pipes statistic tells you how many named pipes and mailslots are open. I talked about this Windows NT feature in the "Understanding the OSI Model" section of Chapter 21.
One of the ways in which this utility will help you on a daily basis is to view the users logged into your workstation. Clicking the Users button in the Server dialog box displays the User Sessions dialog box shown in Figure 22.6. The top half of the display shows you which users are connected. The bottom half shows the resources they're using. Moving from user to user changes the bottom half of the display to show which resources that user has requested.
Figure 22.6. The User Sessions dialog box can tell you a lot about the users connected to your workstation.
Notice that you can disconnect users in two ways. The first is to select a specific user and click the Disconnect button. Clicking the Disconnect All button disconnects all the users connected to your workstation.
So how does this dialog box help you (besides disconnecting users)? A lot of applications don't recover very well if you simply disconnect the user when you log off. Disconnecting users this way can lead to data loss. In fact, disconnecting a user always displays the message box shown in Figure 22.7.
Figure 22.7. Simply trying to disconnect users displays this message box warning you of potential data loss.
The User Sessions dialog box provides an alternative to simply disconnecting someone connected to your workstation. All you need to do is view the list of users and give them a call (either on the phone, through the company paging system, or with e-mail). Hopefully, they'll be at their desks so they can log out of your workstation gracefully. Obviously, asking the network administrator to log them out for you is another alternative. Needless to say, providing a way to determine who is logged onto your system is one way to save the data stored on your machine.
There's another way to view the connections to your machine. You can look at the resources you've provided for others and see who is using them. All you need to do is click the Shares button in the Server dialog box to see the Shared Resources dialog box. Notice that the top half of this dialog box contains a complete list of resources and the number of people using them. Selecting a resource currently in use displays a list of users in the bottom half of the dialog box, as shown in Figure 22.8.
Figure 22.8. The Shared Resources dialog box provides you with a complete list of the resources you're sharing with other people and who is using a particular resource.
Notice that this dialog box also includes both Disconnect and Disconnect All buttons. I described how to use these buttons in the preceding section, so I won't go through them again here.
There is yet another way to view resources from within the Server dialog box. Just click the In Use button and you'll see the Open Resources dialog box shown in Figure 22.9. Notice that it contains a list of resources that any user has open. You'll also see the number of open file locks for that resource.
Figure 22.9. The Open Resources dialog box provides a list of resources that are currently in use.
Unlike the Shared Resources dialog box, the Open Resources dialog box allows you to disconnect a single resource instead of everything that a user has open. This comes in handy in a number of ways. The way that I use it most often is if an application terminates on the other workstation unexpectedly. This usually leaves the resource open, even though no one is using it. All you need to do is select the resource left open by the errant application and click the Close Resource button to close it. You can click the Close All Resources button to close all open resources on your machine. You might use this at the end of the day after everyone has logged out.
Because the number of resources open at any time fluctuates, the Open Resources dialog box gives you a snapshot of the resources open on your computer at the time you open the dialog box. If you want to update this view, click the Refresh button. Windows NT will take another snapshot of the system and display it for you.
Both Windows NT Server and Windows NT Workstation support directory replication. So what is directory replication? You create a set of exported directories on a file server. The various workstations import these directories. Any changes to the contents of the directories on the server are reflected on the workstations automatically. You can use this capability to create a standard directory setup for all the machines on a network.
Replication provides more than mere convenience. Think about it this way: How much time does a user waste accessing some common directories on the network? Using replication provides two benefits over drive mappings. First, the user sees a local connectionand indeed, it is a local connection from a performance perspective. Also consider some of the drive-mapping situations you can get into. A change in system configuration could make a big change in your drive mappings and introduce subtle flaws in your workstation setup. That's a lot less likely to happen with directory replication because it uses a local drive.
You have to have a way to monitor the replication support Windows NT offers. Clicking the Replication button in the Server dialog box does just that. It displays the Directory Replication dialog box shown in Figure 22.10. This shows what you'd see in the workstation version of Windows NT because it only imports replicated directories from a server.
Figure 22.10. The Directory Replication dialog box shows the current status of directory replication on your workstation.
Using this dialog box is easy. Before you can use it, however, you need to enable the Directory Replication Service by giving it a logon account on the server. The account must have a password that never expires, provides the Backup group access rights, and is available 24 hours a day. I tell you all about security and access rights in Chapter 23, "Security Issues."
Once you've gotten an account to use, you'll need to do a little work in the Directory Replication dialog box. All you need to do is select the Import Directories option. Windows NT automatically provides a value for the To Path field. You can change this value if you want, but it's normally a good idea to leave this field alone. Selecting a server to import directories from comes next. Click the Add button and you'll see a Select Domain dialog box like the one shown in Figure 22.11. Select a domain from the list provided, click OK, and you're ready to go.
Figure 22.11. You use the Select Domain dialog box to select a replication server to import directories from.
The final area we'll look at in the Server dialog box is the Alerts button. I'm going to talk about how you set up an alert in Chapter 23 as part of a security plan. The question you need answered now, however, is what to do with those alerts. Normally, they are recorded as part of a log, but wouldn't it be nice if you could also send a message to the network administrator?
Windows NT Workstation provides this capability. All you need to do is click the Alerts button to display the Alerts dialog box shown in Figure 22.12. Using this dialog box is simple; all you need to do is type the name of the administrator or a computer that you want to alert. I normally use the administrator name unless there's a central computer used by more than one administrator. In that case, you'll want to send the alerts to that computer. Remember to type computer names with an initial double backslash like this: \\MAIN.
Figure 22.12. You use the Alerts dialog box to send alert messages to another computer.
What is bindery emulation? Versions of NetWare prior to 4.0 used something called a bindery to store information about the network setup. The bindery contained a list of user names and their rights. In this respect, the bindery is nothing more than a database used by the NetWare operating system. You could theoretically compare it to the registry used by Windows, but the content of the bindery is somewhat different. Think of the bindery as a security element within NetWare and you'll have a better idea of how it actually works.
When NetWare 4.x came along, Novell introduced NetWare Directory Services (NDS), an object-oriented approach to managing network resources. They also introduced something called bindery emulationa way to make NetWare 4.x look like it's using the older bindery rather than NDS. In essence, bindery emulation is a way for people to move from NetWare 3.x to 4.x with a few less problems. I'll get more into this topic in the next section. What you need to know for now is why Novell introduced NDS.
The bindery has more than a few limitations. It's machine-specific, for example. If you add a user to one file server, that user doesn't automatically appear on any other file server; you have to manually add him at each file server. NDS provides a global approach to network management: One utility allows you to view the entire network and add users with ease. Another problem is that the bindery requires special backup procedures. Even though Novell took great pains to protect the bindery from damage, the user still needs a backup copy for those times when damage does occur. There isn't anything the operating system can do about a failed hard drive, for example; you have to replace it and then restore the bindery to reproduce your configuration. I'm not going to discuss every flaw in the binder here; suffice it to say that NDS introduces some features that definitely make life easier for the network administrator.
Still, the bindery is a viable way to go for smaller businesses. If you only have one file server, adding users under bindery emulation isn't any more difficult than adding them with NDS. I also find that the older versions of NetWare are easier to understand from a user perspectiveespecially if those users moved from DOS to Windows over the past few years. Under bindery emulation, you log into a file server without much more than your name and a password. NDS introduces some twists that some users find difficult, if not impossible, to get around. (One of the most common problems I've run into is trying to explain what a context isI'll talk more about this topic in the next section.)
Peter's Principle: Making the Bindery Versus NDS Choice
Technology is changethere isn't any doubt about it. I can even say that it doesn't always mean a change for the better, but it always involves change of some kind. A lot of programmers I know of fought the upgrade from C to C++ in recent years. They saw C++ as a change for the worse because the programmer lost a little more contact with the hardware. On the other hand, proponents of C++ see it as a more natural way to write applications. Even though C++ offers a lot in the way of features, some programmers stuck with the older procedural language. The problem isn't one of shortsightedness but of personal comfort. These folks felt very comfortable in the world of procedural languages, and the idea of moving to the world of object-oriented programming (OOP) scared them.
If programmers can run into difficulty when it comes to change, it's no wonder that the users of the products they create can run into the same problem. NDS represents a move from the world of the familiar DOS prompt to a new one that uses object-oriented technology. All those DOS utilities use a procedural approach to managing the network. Using NDS means learning a new way of doing things, and that makes folks feel uncomfortable. When you use the DOS utilities, you see things in relation to the hardware. Likewise, using NDS means taking a real-world approach to viewing the networkone in which the hardware is a means to an end.
So what's the connection here? C++ and NDS both offer an object-oriented view of the computer world. Think about it this way: You deal with objects every day in the real world. When you pick up an apple, you don't think about a procedure for eating it; you think about its taste and smell. These are the properties of the apple. Biting is a method of interacting with the apple, and chewing it is an event. You know that you're doing these things, but the process for doing them isn't important. Likewise, object-oriented technology helps you think about the computer in terms of the real world. You know that you have users, workstations, servers, printers, and other resources. What you're really concerned about is the way in which these various network elements interact with each other, not the process for allowing them to do so. A user has certain rights and you need to know certain things about him, such as his location, name, and telephone number. All these things are the user's properties. How the user can interact with the network are methods. You might decide that he can change his own password, but not anyone else's, for example. When a user does interact with the network, it's an event. NDS provides utilities for monitoring those events in a real-world way that makes a lot more sense than some of the auditing utilities you used at the DOS prompt.
NDS provides all these real-world views of the networka view that you're used to using. To gain the efficiency, knowledge, and other benefits of a real-world view, you need to give up a little comfort and learn a new way of doing things. I think it's worth it. Using bindery emulation when you have NDS available is like thinking about the procedure for eating an apple instead of what it tastes and smells like. NDS is your doorway to a new world of network management in which everything is presented in terms that you can really understand.
For right now, let's take a look at some of the utilities that older versions of NetWare (pre-4.x) provide. I'm not going to provide you with a complete list of every utility because some of them aren't all that useful under Windows NT. What I want to do is make you aware of their presence so that you can use the full capabilities of the file server. What I'm really giving you is a whirlwind tour of NetWare 3.x utilities. Make sure that you spend some time in the documentation learning about the full capabilities they provide.
One of the things you'll commonly need to do under NetWare is check what rights you have in a particular directory. I've run into more than one situation in which a user ran into problems with an application because he didn't have sufficient rights to the application or data directories. NetWare provides three utilities you can use to determine your rights: RIGHTS, FILER, and FLAG.
Let's take a look at the two command-line utilities first. Figure 22.13 shows the results of using the RIGHTS command. Notice that NetWare tells you exactly what you can do in this particular directory but doesn't say anything about file access. You use the FLAG command-line utility to determine your access rights to a file. Figure 22.14 shows the results of using this command.
Figure 22.13. The RIGHTS utility tells you your rights in a specific directory.
Figure 22.14. Use the FLAG utility to determine your rights to a specific file.
For the most part, you won't need to use FILER unless you want to explore the file server drives or set directory/file rights. Figure 22.15 shows what you'll see when you initially open FILER. The first two options allow you to view your rights in the current directory. The Directory Contents option is file-specific. You'll use the third option, Select Current Directory, to move from place to place on the current hard drive. The fourth entry, Set Filer Options, allows you to configure FILER for use. In most cases, you'll find that the default settings work just fine. The Volume Information option displays the size and available space on the current volume.
Figure 22.15. The FILER utility allows you to view and set both file and directory rights.
Let's take a quick look at the Current Directory Information option. Figure 22.16 shows what you'll see if you select it. The first field tells you who owns the directory. If you have the proper rights, you can select this field and take ownership of the directory. Next, you'll see the creation date and time fields. NetWare allows you to change these entries as well. I've used this feature on an occasional basis for version stamping a directory. You can use the date as the last date you modified a specific version of the files. The time normally signifies the version number, with hours representing the major version number. The Directory Attributes field contains a list of attributes for the current directory; they work much like the file attributes under DOS with a NetWare twist. You'll also see two security-related fields here: Current Effective Rights and Inherited Rights Mask. I'll describe these two entries in Chapter 23, so I won't talk about them here. The final field tells you who has trustee rights to this directorythose people that can access it in any way.
Figure 22.16. The Directory Information dialog box tells you all about the current directory.
Selecting the Directory Contents option from the main menu gives you an overview of what the current directory contains (see Figure 22.17). If you highlight one of the files and press Enter, FILER displays a menu containing five options. The first three options allow you to view, copy, or move the file. The fourth option, View/Set File Information, displays the dialog box shown in Figure 22.18. Notice that it tells you all about the file's security settings. Even more important for NetWare and Windows NT is the name space support for the file and the size of its extended attribute (EA) file. Finally, the Who Has Rights Here option tells you who can access the file and in what way they can access it.
Figure 22.17. The Directory Contents option of FILER tells you about the files and subdirectories in the current directory.
Figure 22.18. You can use this File Information dialog box to learn detailed information about the selected file.
You don't have to resort to using FILER to grant people rights to a particular file or directory. NetWare also provides a GRANT command-line utility. All you need to do is specify the level of access you want to provide, the name of the directory or file you want to grant access to, and the name of the person or group. If you leave out the directory or file argument, GRANT assumes that you mean the current directory. Similarly, leaving out the user or group name assigns the access to everyone. The rights list is the same one I'll talk about in Chapter 23. Two additional parameters (/Files and /Subdirectories) allow you to extend these rights to all files and/or subdirectories.
Because the file server is the central core of everything you do on the network, it pays to know how to check it. There are two utilities to get the current file server status: FCONSOLE and RCONSOLE. Each utility serves a different purpose under NetWare.
FCONSOLE allows you to view the file server status but doesn't allow you to do much with it except shut it down. You can also use this utility to broadcast messages to workstations on the network. Its main screen appears in Figure 22.19. Notice that there are actually two message-broadcasting options. You can choose to send a message to all the workstations on the network by using the Broadcast Console Message option, or you can send it to an individual by using the Connection Information option. You can also use the Connection Information option to view user specifics, such as network addresses and login times.
Figure 22.19. FCONSOLE gives you a quick view of the current server status and allows you to send console messages to others on the network.
The Status option of FCONSOLE allows you to determine the current file server time and date. You can also use it to enable or disable logins and transaction tracking. Disabling logins allows you to keep users out while you perform file server maintenance. The Version Information option tells what version of NetWare you're using and how many users it supports.
Before you can use RCONSOLE, you have to load the RSPX.NLM at the file server console. This loads the required protocol drivers and interface module (REMOTE.NLM). After you load the file server console, you can load RCONSOLE. Figure 22.20 shows what the initial RCONSOLE display looks like. All you need to do is select one of the servers in the list and type a password. What you'll see next is the same thing you would see if you were working at the file server console itself. You can load and unload NetWare loadable modules (NLMs) and use the MONITOR.NLM to check the complete status of your file server. If you don't see the server you want, make sure that you've loaded both RSPX.NLM and REMOTE.NLM at the file server console.
Figure 22.20. RCONSOLE provides complete access to your file server console from a remote location.
The preceding section provided you with a lot of information about the command-line utilities NetWare provides, so I won't go through them again here. NetWare 4.x provides a lot more in the way of user aids than command-line utilities, however. The big news, as far as I'm concerned, is the centralized management you get with NWADMIN.
Note: If you want to use NDS on a network with a combination of Windows NT and Windows 95 workstations, make sure that you download Service Pack 1 for Windows 95 from Microsoft. You can find this in their Software Library forum on CompuServe. Just GO CIS:MSL-30 and look for SNumber S15768. You can also get the Service Pack 1 update on Microsoft's Internet Web page. Use the following URL to go directly to the download area:
http://www.microsoft.com/windows/software/servpak1/enduser.htm
As an alternative to the Microsoft offering, you can download the Novell version of Windows 95 support from their NetWire forum on CompuServe. Overall, I found the Novell offering more feature-rich but slower than what Microsoft provides. An average user will want to use the Microsoft product for its speed; an administrator will want the added features provided by Novell.
Figure 22.21 shows what the NWADMIN utility looks like when you first open it. You'll see a list of network objects, including users, servers, groups, printers, and just about any other kind of organizational unit you can think of. You can even create an organizational hierarchy based on your company's current structure by adding departments. This figure shows an extremely simple layout; obviously, NDS is capable of a lot more than I'm showing you.
Figure 22.21. NWADMIN provides a hierarchical view of your organization, making it easier to manage your network.
Peter's Principle: Keeping Console Commands Handy
It's pretty likely that if you're an administrator for a small network, you'll end up wearing several hats. Someone who only has to work on the network on an occasional basis might find it easy to forget all those long-winded console commands that Novell provides.
Very few people realize that you can create console batch filesjust like the ones you use with DOS on your workstation. The difference is that you use an NCF extension in place of the normal BAT extension.
Suppose that you have a problem remembering the TRACK ON and TRACK OFF commands. Just stick them in a batch file and use a name you will remember. When you need to use TRACK ON, just type the name of your batch file at the console prompt, andvoilãyou'll see the results on-screen.
You can make the batch files as long as needed and even display comments on-screen by using the ECHO command. The only requirement for using batch files under NetWare is that you place them in the SYS:SYSTEM directory to make sure they're always accessible.
It won't take you long to figure out that NWADMIN replaces all the old DOS utilities you used to use with one centralized management environment. Obviously, it replaces SYSCON and FILER without any problem; a simple glance shows that. Not so noticeable in Figure 22.21 is that it also replaces all your print-oriented utilities and allows you to monitor everything on the network with relative easealthough not in the way that the Windows NT monitoring tools we covered in Chapter 3, "Performance Primer," do.
That brings me to what Windows NT 4.x doesn't include. You won't find a graphic version of the RCONSOLE utility. Even though you'll find a menu entry for it in NWADMIN, RCONSOLE is still a DOS application that requires a DOS window to run in. You'll also find that NetWare 4.x is lacking the FCONSOLE utility, but let's face the fact that this utility was getting pretty close to useless in the 3.x version. It certainly didn't provide the functionality the 2.x version of FCONSOLE did, and for good reasonthere are other ways for a network administrator to gain access to the file server console.
As with most good Windows products these days, NWADMIN provides a wealth of alternatives to using the menu. Figure 22.22, for example, shows the context menu you'll see for most of the objects you can create with NWADMIN. There are only six entries on this menu, but they provide access to most of the things you'll need to do within NWADMIN.
Figure 22.22. NWADMIN provides a fully functional context menu.
The NWADMIN context menu offers these options:
There are two DOS utilities that I would like to make you aware of. The first is NETUSER. The initial screen for this program appears in Figure 22.23. This is a user-oriented tool designed to make NetWare easier to use. Most of the menu options are pretty obvious. The Printing option, for example, displays a list of printer ports and tells you whether they're local or captured to a network port. You can use the Messages option to turn on or off broadcast messages. It also allows you to send messages of your own to other users. The Drives option allows you to see your drive and search mappings.
Figure 22.23. NETUSER allows a user to modify his environment.
Things get a bit more complicated when you use the Attachments option. This displays a list of all the servers you're connected to. Each server provides the same list of configuration options. All you need to do is highlight a server and press Enter to see a list containing the options Login Script, Password, and Server Information. Each user is allowed to modify his own login script. You used to find this functionality in SYSCON. The same holds true for the Password entry, which allows you to change your password for that server. The Server Information screen replaces the one you used to find in FCONSOLE.
The last option is Change Contextthe entry that most users get lost at. Remember that NDS uses an object-oriented approach to management, so you have to provide it with a bit more information. A context is where you're at in the hierarchy. If your organization name is ABC_CORP and you're in the editorial department, for example, your context might be Joe.Editorial.ABC_Corp. If you want to change your contextyour location within the treeto Sales, you might type Joe.Sales.ABC_Corp. Changing your context often means a change in the rights you have. A network administrator may choose to give you several contexts to reduce the amount of network traffic or to make it easier for you to navigate the network. Remember the view in Figure 22.21 when you think about what you need to type here. Each node on the tree begins with a dot (.), except for your name. All you need to do is trace your position in the tree, starting with your name, and type each node name as you go up to the root (the beginning of the tree). Obviously, you'll have to have more than one entry on the tree to be able to change contexts.
Let's take a look at the last utility: NLIST. This is a command-line program that allows you to list network resources like your current server or context. Figure 22.24 shows an example of the output from this utility. In this case, I displayed a list of users. You can also use this utility to display a list of groups, servers, printers, and other network resources.
Figure 22.24. NLIST provides a lot of helpful information about the network configuration.
If you have access to the Server applet, take some time to learn its various features. How would you use the user information to ensure that everyone is logged out of your machine before you shut down at night, for example? What could you do about open files if there is no one logged into your workstation? Knowing how to get around these problems before you actually need to do so can save a lot of frustration later.
Look at the login script for your computer. Try to figure out the purpose for each command it contains. Are there any commands that you no longer need for Windows NT (the Greeting command falls into this category)? Try getting rid of any excess commands and see how long it takes to start your workstation after you log in. Do you notice a decrease in script processing time?
NetWare provides access to a lot of different utilitiessome of which are available to the average user (others require administrator access). Spend some time looking at the various utilities you can access and see what they're used for. Take the time to read through the NetWare manuals and really learn how the operating system works. How does the NDIR command differ from the DOS DIR command, for example?